\subsection{Projektablauf}
Die Entscheidung für die Realisierung dieses Projektes fiel bereits lange bevor wir uns darauf festlegten es im Rahmen der Diplomarbeit umzusetzen. Die Projektidee kam zu Beginn der 4. Klasse von Herrn Dipl. Ing. Andreas Sperrer, welcher vorschlug im Rahmen des Freifachs Spieleprogrammierung mit der Programmierung und Planung eines einfachen Roboters zu beginnen, zu diesem Zeitpunkt bestand bereits der Gedanke das Projekt später als Diplomarbeit weiterzuführen. Das Projektteam setzte sich in dieser ersten Entwicklungsphase noch aus Philipp Stelzer, Matthäus Kücher und Florian Nöhammer zusammen. Das Hauptaugenmerk im laufe des Schuljahres 2010/11 lag vorerst auf der Beschaffung der benötigten Teile, der Erstellung einer ersten Zieldefinition und der Anstellung grundsätzlicher Überlegungen zur Ansteuerung der Motoren.\\

Der Entschluss das Projekt weiterzuführen fiel erst Anfang Mai 2011, als Matthäus Kücher und Florian Nöhammer als mögliche Projektmitarbeiter weggefallen waren und sich David Maier als neuer Mitarbeiter herauskristallisierte. 
Die zu dieser Zeit gesetzten Zielvorstellungen weichen vor allem im Hardware Bereich mehr oder weniger stark von der schlussendlich realisierten Lösung ab. Als Hauptgrund für diese Abweichungen können die, durch Veränderungen an den finanziellen Rahmenbedingungen herbeigeführte, mehrmalige Abänderung der vereinbarten Anforderungen gesehen werden. Die Anforderungen für das Anwenderprogramm veränderten sich nur minimal und wurden auch so umgesetzt wie ursprünglich vereinbart.
Die folgenden Punkte sollen einen groben Überblick über die Entwicklung der Anforderungen an den hardwarenahen Teil des Projektes bieten:
\begin{itemize}
\item \textbf{Ursprüngliche Anforderungen:}\\
Die Ursprüngliche Anforderung an dieses Projekt aus Sicht der Hardwareentwicklung war es, einen einfachen Scara Roboter herzustellen. Da die Auswahl der benötigten Schrittmotoren und der dazugehörigen Steuerungen bereits im Vorfeld getroffen worden war, war das Hauptziel, auf Basis dieser Komponenten eine funktionsfähige und solide Mechanische Umsetzung zu finden, sowie die Steuerung der Motoren in Echtzeit zu ermöglichen.
Die dritte, vertikale Achse, welche von der Scara Architektur vorgegeben wird, war nach dieser Anforderung zwar geplant, galt jedoch nicht als Muss-Kriterium, da ihre technische Umsetzbarkeit in der vorgegebenen Zeit als nicht gesichert schien.
\item \textbf{1. Änderung der Anforderungen:}\\
Durch eine freundliche Spende der Firma KEBA wurde unsere Schule ende 2011 mit zahlreichen Speicherprogrammierbaren Steuerungen und dazu passenden Drehstrom Servomotoren inklusive Motorsteuerungen ausgestattet. Aufgrund dieser nicht geplanten Veränderung der Ausgangssituation kam es auch zu einer radikalen Veränderung der Anforderungen an die Hardware Konstruktion des Projektes. 
Mit Blick auf die Vorteile der neuen Hardware wurde kurzerhand die Entwicklung der bisherigen Hardware in den Hintergrund gestellt und verstärkter Wert auf die Entwicklung einer wesentlich größeren und leistungsfähigeren Lösung mit der neuen Hardware gelegt.\\
Hauptziel war ab diesem Zeitpunkt die Planung und der Bau eines Roboter Arms mit zwei rotatorischen Achsen aus Aluminium.

\item \textbf{2. Änderung der Anforderungen:}\\
Während der Planung des Aluminium Roboters durchgeführte Machbarkeitsstudien wiesen auf größere Probleme mit der Finanzierung fehlender Teile hin, welche innerhalb unserer zeitlichen Grenzen als nicht lösbar erschienen. Auf Basis von Rücksprachen mit dem Auftraggeber fixierten wir schlussendlich die im Kapitel Aufgabenstellung beschriebenen Anforderungen an die Endausfertigung des hardwarenahen Teils.
\end{itemize}
Das Projekt wurde im Laufe des Schuljahres 2011/2012 entwickelt und durchlief vor allem im März und April 2012 eine Phase sehr intensiver Entwicklung.\\
Nach einer kurzen Testphase wurde das Projekt schließlich am 10. Mai 2012 in der finalen Version 1.0 abgegeben. Hierbei ist zu beachten, dass die Versionsnummern für die Einzelnen Teilbereiche aufgrund des losen Zusammenhangs grundsätzlich unabhängig vergeben werden. Zur Vereinheitlichung wurde für die abgegebene Version bei jedem Teilbereich als erste Versionsnummer 1.0 gewählt. 
